At 8:16 AM 7/9/95, fc@all.net wrote: > I was trying a loop test to stress performance on our secure W3 >server and found that inetd under SunOS detects what it thinks to be >loops and shuts down all httpd services untill a kill -HUP is sent to >the inetd process. How is this bug/feature controlled, and doesn't this >lead very directly to denial of services attacks? I think this bug/feature is fairly widespread. Below are some extracts from the old (pre-4.4lite) BSD sources (ftped off uunet a year or two back): What this comes down to is that inetd shuts down a service if more than a particular number of request per minute come in, for a fixed period of time (presumably as a defense against run-away client software.) >#define TOOMANY 40 /* don't start more than TOOMANY */ >#define CNT_INTVL 60 /* servers in CNT_INTVL sec. */ >#define RETRYTIME (60*10) /* retry after bind or server fail */ > if (dofork) { > if (sep->se_count++ == 0) > (void)gettimeofday(&sep->se_time, > (struct timezone *)0); > else if (sep->se_count >= TOOMANY) { > struct timeval now; > > (void)gettimeofday(&now, (struct timezone *)0); > if (now.tv_sec - sep->se_time.tv_sec > > CNT_INTVL) { > sep->se_time = now; > sep->se_count = 1; > } else { > syslog(LOG_ERR, > "%s/%s server failing (looping), service terminated\n", > sep->se_service, sep->se_proto); > FD_CLR(sep->se_fd, &allsock); > (void) close(sep->se_fd); > sep->se_fd = -1; > sep->se_count = 0; > nsock--; > if (!timingout) { > timingout = 1; > alarm(RETRYTIME); > } Unfortunately these time constants were originally hardwired in the code and computers have been getting faster. We met this bug when it shut down a widely used service on our campus. There are patches for various versions of Unix and changes in the newer BSD sources that add a parameter to inetd that allows changing the cutoff rate of requests per minute. But this doesn't really solve the problem of denial of service... though one might argue that having some upper limit controls another kind of denial of service, a 10 minute total shutdown of the service is a drastic remedy. --- Albert Lunde Albert-Lunde@nwu.edu